home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16443 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  56 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: Re: word vs. byte alignment option
  5. Message-ID: <marnoldDpn1Ax.4ox@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <4kdq3b$lhn@sloth.swcp.com>
  8. Date: Wed, 10 Apr 1996 08:37:45 GMT
  9. Sender: marnold@netcom23.netcom.com
  10.  
  11. dvines@sparton.com (Dudley Vines) writes:
  12.  
  13. >Anybody ever have trouble with Borland C++ compiler word vs. byte 
  14. >alignment option?  When I attempt to load a word aligned array into a byte 
  15. >aligned array, the data in the byte aligned array is off by one byte.
  16.  
  17. This is to be expected.
  18.  
  19. >The arrays come from separate modules with different alignement options 
  20. >set.
  21.  
  22. >I thought the alignment option only affected speed or memory usage...why 
  23. >doesn't the compiler figure out how to handle the data right?
  24.  
  25. Alignment *primarily* affects the alignment of *data*, for the purposes
  26. of affecting speed and/or memory usage.  Different alignment options
  27. can change how the complier lays out structs, for example.  With word
  28. alignment, it may "pad" (insert dummy bytes) in between char members of 
  29. a struct so they all align on word boundaries, for example.  This is is 
  30. why it's called "alignment".
  31.  
  32. You can't compile to different pieces of code for differing alignments 
  33. and expect them to be able to share data structures, unless you force 
  34. some common alignment for those shared data struuctures.  Having apparently
  35. not done this, the kinds of problems you are getting are no surprise.
  36.  
  37. Why are you adjusting the alignment anyway?  Do you have any concrete
  38. proof that some particular alignment will somehow improve the performance
  39. of you code?  How much of that supposed time-savings has been wasted 
  40. tracking down alignment-related bugs?  Just a thought.
  41.  
  42. First, get your code working.  Second, identify possible performance 
  43. issues.  *Then* decide if a change in alignment is appropriate.  
  44. Depending on CPU, compiler and type of code in your program, a change in
  45. alignment might be one of the least effective performance tuning options.
  46. It might even make things worse.
  47.  
  48. Regards,
  49. -------------------------------------------------------------------------
  50. Matt Arnold                       |        | ||| | |||| |  | | || ||
  51. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  52. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  53. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  54. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  55. -------------------------------------------------------------------------
  56.